Gordon Moore, the cofounder of Intel Corporation, made an observation and prediction that semiconductor performance would double every 18 months, with the price of the new product remaining constant with the old. This observation is now referred to as Moore's Law, and has remained relatively accurate since the early 1970s. Moore's Law illustrates the rapid advancement that has and is taking place in the electronics industry. Because of this rapid advancement, the market window for many electronic products is relatively short, with faster and more powerful devices being continuously introduced. Accordingly, there is great pressure to reduce the development time for many products. To significantly reduce the development time for most electronic devices, the design time must be reduced, as the design process typically consumes a majority of the development cycle.
FIG. 1 shows a typical prior art design process for an ASIC (Application Specific Integrated Circuit) device. ASIC devices are commonly used to implement large and/or high performance circuit designs. In a first step, a hardware architect typically determines the requirements for the circuit design and formulates an underlying framework of the function and projected performance characteristics of the circuit design. The architect documents these ideas in a functional specification, as shown at step 12.
The design is then partitioned into a number of blocks and given to one or more logic designers for implementation. The logic designers create a detailed logic design using the functional specification as a guide. Rather than creating schematics, many logic designers express their design in a behavioral language such as VHDL (VHSIC Hardware Description Language), as shown at step 14. Many logic simulation tools can directly accept behavioral language descriptions as input. This not only improves efficiency in developing complex circuit designs, but also allows various sections of the circuit design to be functionally verified before the entire design is complete.
Next, and as shown at step 16, the design is typically logically simulated to verify the functionality thereof. To logically simulate the design, the circuit designer typically provides one or more test input files. The test input files may include a number of test conditions expressed as test vectors or the like. Each of the test vectors may include a value for selected inputs of the circuit design along with an expected circuit response. The logic simulator reads the test input files, simulates the behavior of the circuit design using the test input, and provides a simulated circuit response. The simulated circuit response is then compared to the expected circuit response to determine if the circuit design provides the expected behavior.
After logic simulation is complete, the design is typically passed to one or more physical designers, as shown at step 18. The physical designers place the various cells that represent the basic logic building blocks of the circuit design, and interconnect the cells using a routing tool. Timing information may be extracted and analyzed by both the physical and logical designers. Some timing problems can be fixed by the physical designer by adjusting the drive strengths of various components or placing cells in a different arrangement relative to each other. As shown at step 22, other timing problems can only be resolved by modifying the logic itself. If a problem is resolved by modifying the logic, the modified design must typically be re-verified by re-executing logic simulation step 16 and then the physical design step 18.
After all the logical and physical changes are made, and the design meets the stated requirements, the design is released for fabrication, as shown at step 24. Fabrication can take several months for a typical ASIC device. Once completed, the device is returned and tested, as shown at step 26. If the device does not meet the stated requirements, a design modification may be required as shown at step 22, forcing another design iteration of the logic simulation step 16, the physical design step 18, and the fabrication step 24. Once the device meets all of the stated requirements, the device is released, as shown at step 30.
In most design processes, it is important to reduce the number of design iterations that are required to produce a fully functional device. One way of reducing the number of design iterations is to increase the fault coverage of the test cases used during the logic simulation process. Increasing the fault coverage, however, tends to increase the time needed to generate and simulate the increased number of test cases. Thus, there is often a trade-off between an increased fault coverage and design cycle time.
FIG. 2 illustrates a prior art logic simulation process. At step 42, the architect and test designer discuss the logic implementation and define a series of test cases that address the various functional sections and possible interactions of the design. In many designs, such as a directory based MSU (Main Storage Unit) with multiple parallel ports and crossbar switches (see below), there are many possible functional operations and interactions that could and should be tested to achieve a high fault coverage. Some test cases can be defined relatively easily. Other test cases, such as those that test the parallel and often conflicting operations of the hardware, can be much more difficult to define and implement.
Once the test cases are defined, the test designer often codes the test cases into a format that can be used to produce an input for the logic simulator. This format may include, for example, a force command, followed by a run command, followed by a force command, etc. Test cases written in this format must typically be interpreted by the logic simulator, and more particularly, by a simulation control program of the logic simulator. The simulation kernel must usually be interrupted before the simulation control program can process a subsequent line in the coded test case. Because the simulation kernel must typically be regularly interrupted, the speed of the logic simulation can be significantly reduced.
To increase the speed of the logic simulation, a test driver may be used. A test driver is typically expressed using a behavioral language description and simulated along with the circuit design. Because the test driver can be actually simulated along with the circuit design, the test driver can stimulate the inputs of the circuit design without having to be interpreted by the simulation control program, and thus without having to interrupt the simulation kernel.
Prior to simulation, the test driver can be loaded with test data for controlling the inputs of the circuit design and verifying the results of a subsequent logic simulation. The test data can be stored in a memory structure expressed within the behavioral description of the test driver. For example, the test data may be loaded into a RAM structure within the test driver, and during logic simulation, the address to the RAM structure may be incremented to provide each of the test vectors to the inputs of the circuit design.
To generate the test data, a designer often codes the desired test cases into a standard programming language like "C", as shown at step 44. When executed, the "C" programs generate the test data, which as indicated above, is later loaded into a memory structure within the test driver, as shown at step 46. The "C" programs may also generate corresponding initialization files that can be loaded into the device under test (e.g. MSU RAMs). To perform the tests, clocks are issued (simulation starts), as shown at 48.
During or at the end of the logic simulation, the results are checked to see if the test passed or failed, as shown at step 50. If the test failed, the results are analyzed to determine whether there was a test problem or an actual logic design problem, as shown at step 52. If a test problem is detected, the test is modified and re-executed as shown at step 56. If a logic problem exists, the logic design must be modified, as shown at step 54, and the logic simulations are re-executed to validate the change. When all of the defined test cases pass, as shown at step 58, the logic simulation process is complete.
A limitation of many prior art test drivers is that they only operate in a master-like mode, and not a slave-like mode. That is, many prior art test drivers only provide test vectors to the inputs of the circuit design, and then verify the response provided by the circuit design. Both of these operations are considered master-like operations because the test driver performs each operation regardless of the operation of the circuit design. If the circuit design does not provide the proper response, the test driver merely reports an error. Prior art test drivers typically do not have the ability to respond to requests provided by the circuit design. Responding to requests provided by a circuit design is considered a slave-like operation because the test driver must accept requests and respond accordingly.
By not providing a slave-like mode, prior art test drivers often cannot efficiently simulate those circuit designs that provide a request back to the test driver and expect a response. For example, in a directory-based multi-port MSU, a requesting port may request ownership of a data element within the MSU. The MSU typically checks the corresponding directory information to determine who currently owns the requested data element. If the MSU owns the requested data element, the MSU simply provides the data element to the requesting port to complete the operation. However, if another port currently owns the requested data element, the MSU typically must issue a return request to the owning port. The owning port must then return control of the data to the MSU before the MSU can provide the requested data to the requesting port. If the port driver models a port of the MSU and cannot respond to the return requests from the MSU, the MSU cannot provide the data to the requesting port. Therefore, prior art port drivers typically cannot be used for simulating these types of operations. Rather, these operations must typically be simulated at a higher simulation level, such as at a system level. However, it is known that it is most efficient to find and remove errors at the lowest simulation level of simulation. Higher simulation levels typically include significantly greater logic, require more simulation hardware resource, provide more redundant simulation of logic that already has been verified, and requires more debug time to trace a signal from the test source to the problem area.
Another limitation of many prior art test drivers is the inability to effectively simulate the interaction of dependent and/or conflicting requests within a circuit design. For many circuit designs, such as multi-port circuit designs, it is often desirable to independently control selected groups of inputs using separate and independently executed test lists. For example, it is often desirable to independently control each port of a multi-port MSU using separate and independently executed test lists. By providing independently executed test list, each port of the MSU is allowed to operate in a non-deterministic manner relative to the other ports. This, in turn, may allow the detection of design errors that can only be detected by simulating the interaction of dependent and/or conflicting requests.
When each of the ports is controlled by a separate and independently executed test list, it is often difficult to determine if a desired sequence of events actually occurred during the simulation. For example, in a test case that simulates the interaction of two independently operating ports of a directory based multi-port MSU, the sequence of events that occur in response to a request from one port may depend on the state of the MSU, including the current owner of the requested data element, and the state of the pending requests from other ports. Thus, if multiple ports request ownership of a common data element in the MSU, it is often difficult to determine by examining a final simulation result if each of the requesting ports actually received the data element, particularly if the MSU issues one or more return requests causing the return of the data element to the MSU during the test.
It would be desirable, therefore, to provide a test driver that can respond to requests provided by a circuit design. This may allow more varieties of circuits to be simulated at a lower level of logic simulation. It would also be desirable to provide a test driver that can help track the sequence of events that occur in response to certain test cases, and in particular, in response to those test cases where the sequence of events is difficult to determine by examining a final result.